home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Micro R&D 5: Mand 2000
/
Mand 2000 - Micro R&D CD-ROM Vol 5.iso
/
documentation
/
mand2000tech.doc
< prev
next >
Wrap
Text File
|
1994-10-20
|
10KB
|
221 lines
Mand2000 Technical Information - Copyright © 1993 Cygnus Software
Please do not distribute.
File Formats
In addition to the regular IFF chunks, such as ILBM, BODY, CMAP, CAMG,
CRNG, CCRT and GRAB, Mand2000 saves some additional custom chunks, to store
such things as the fractal location, julia seed, colour mapping settings,
and iteration information. To facilitate the writing of support programs
for Mand2000, all of the custom chunks are documented here, with some
sample source code.
Standard Chunks:
First, some information about how Mand2000 uses the standard chunks.
In the ILBM chunk, the page width and page height that Mand2000 writes are
the size of the screen, and the w and h fields are the width and height of
the drawing area of that window. Page width and page height will always be
equal or greater than w and h. When loading, Mand2000 attempts to
interpret page width and page height in the same way.
The GRAB chunk is used to store the pixel location that was used for
the last zoom in. This information is ignored by Mand2000 but is crucial
to the TweenPlayer as it tells it what point to zoom in on when playing
back a tween movie. If these chunks are lost then the tween movies will
not play back properly. Tween movie playing of arbitrary pictures can be
done by adding GRAB chunks to the files with appropriate x,y coordinates.
Custom Chunks:
The most important chunks are the location chunks. These specify the
coordinates of the left, top, right and bottom edges of the saved image.
The demo version of Mand2000 never saves these chunks, but the production
version always does, except when you save a palette or a screen. This
information is always stored twice, in two separate chunks. The first
chunk is the same one used in MandelMania, thus insuring file compatibility
with that program. Mand2000 also reads Mandelblitz and TurboMandel custom
chunks but does not write them. Reading and writing of more custom fractal
chunks would have been provided if the authors of these programs had
documented their chunks.
The following information has been extracted from the MandelMania
documentation. Thanks to Markus for making this information available.
> To store specific picture parameters, a special chunks are built in. The
> most important one called "MAND". The structure of this chunk is as follows:
>
> struct MAND_Chunk {
> USHORT LeftEdge,TopEdge,Width,Height; /* windowcoordinates */
> long double xleft,xright,ybottom,ytop; /* range */
> long double xconst,yconst; /* Julia constant */
> ULONG Iterations; /* max number of Iterations */
> ULONG Type; /* Type, see below */
> };
>
> Remember that a 'long double' is 12 Bytes (=96 bits) long.
>
> Mand_Chunk->Type can be one of the following:
>
> #define TYPE_MANDELBROT 0
> #define TYPE_JULIA 1
The MandelMania chunk is probably the easiest one to use because the
numbers are stored as simple long doubles that your compiler understands.
However this format does have finite accuracy. At magnifications much
beyond approximately one thousand million million long doubles are no
longer sufficient. This may seem like a lot, and often is, but sometimes
zooming beyond that is nice, and Mand2000 does support it, which is why we
have the FXPL, FXL2, FXPJ and FXJ2 chunks. FXPL and FXL2 store the fractal
location, and FXPJ and FXJ2 store the julia seed location, if applicable.
The reason that there are two formats for each of these purposes is because
the FXPL and FXPJ formats, which were initially used by MandFXP in 1986
(also by CygnusSoft) didn't allow for storing of coordinates greater than
+-3.99. Since Mand2000 allows zooming way out, as well as way in, the FXL2
and FXJ2 chunks were defined. FXPL and FXL2 are never used at the same
time, similarly FXPJ and FXJ2 are never used at the same time - a good
reader will check for both, but FXL2 and FXJ2 are only used if the fractal
has been zoomed out. Before explaining the chunks further I'll give the C
language declarations for them.
#define NUMLONGS 36
#define NUMCOORDINATES 4 /* Left, right, top and bottom. */
#define NUMJULCOORDINATES 2 /* JuliaX, JuliaY */
/* Size equals sizeof(UWORD) + PRECISION * sizeof(short) * NUMCOORDINATES. */
struct LocationData
{
UWORD CurrentPrecision;
short coordinates[NUMLONGS*2*NUMCOORDINATES];
};
struct JuliaPointData
{
UWORD CurrentPrecision;
short coordinates[NUMLONGS*2*NUMJULCOORDINATES];
};
Because Mand2000 can zoom in extremely far, these structure need to be
able to hold extremely precise numbers. The current maximum accuracy is 36
long words, or 144 bytes per number. Since it would be rather inefficient
to store the entire 144 bytes per number when it wasn't all used, the
CurrentPrecision field specifies how many words of data are stored for each
coordinate. Typically CurrentPrecision is equal to the calculation
accuracy plus one. The number of words stored in a LocationData chunk is
equal to CurrentPrecision times four plus one. The number of words stored
in a JuliaData chunk is equal to CurrentPrecision times two plus one. The
coordinates in the FXPL chunk are stored in the order left, right, top and
then bottom. The coordinates in the FXPJ chunk are stored in the order
juliax, juliay.
The numbers are stored as fixed point numbers, with the decimal point
stored after the third bit. They are stored in standard Motorola twos
complement format (normal binary number format), as a stream of bits with
the highest precision bits coming first. As an example, if
CurrentPrecision was two, and the location was -3.0,+3.0,+2.0,-2.0, a total
of nine words would be written out to the FXPL chunk as follows:
0x0002 = number of words per number
0xA000 = left = -3.0 with the decimal point after the third bit.
0x0000 = the rest of left.
0x6000 = right = 3.0 with the decimal point after the third bit.
0x0000 = the rest of right.
0x4000 = top = 2.0 with the decimal point after the third bit.
0x0000 = the rest of top.
0xC000 = bottom = -2.0 with the decimal point after the third bit.
0x0000 = the rest of bottom.
The data format of the FXL2 and FXJ2 structures is identical, except
that instead of there being three bits to the left of the decimal point
there are nineteen bits to the left, in other words there is one additional
word of data to the left of the decimal point. CurrentPrecision still
contains the number of words stored per number and the formulas above for
calculating chunk size still hold, however the numbers stored can be 65536
times larger, allowing zooming out well beyond the interesting areas of the
fractals. The additional binary digits to the left should be ones if the
number is negative, zeroes if the number is positive.
Some more miscellaneous information is stored in the FXD2 chunk. The
structure of this chunk is as follows:
struct OtherFractalData
{
short Size; /* NEVER load more than you know how to deal with. */
/* NEVER load more than the structure contains. */
short VersionNumber; /* Currently always zero. */
short actualmaxiter; /* Maximu iterations. */
short numpasses; /* Zero to three. */
short mindrawcolour; /* Purely advisory - first colour to draw with. */
long morphfactor; /* 0-32768, translated to 32768-0 on load so that 0 maps to 1.0 instead of 0.0 */
/* Stored with an extra word of precision for accurate continuance of morphs. */
/* The extra word might not be used. */
short colourmaptype; /* 0 is the old fashioned linear wrap-around type. */
short colourmapskip; /* This is taken straight from the colour map */
/* requester, as are colourmaptype and colourmap */
/* offset. */
short fractaltype; /* A number from zero to five (currently). Odd */
/* numbers represent julia sets, even numbers */
/* are Mandelbrot (0), Mandcubed (2) and */
/* Mand fourth (4). */
short colourmapoffset;
};
If you save a Mand2000 picture when it hasn't finished calculating, an
additional chunk is saved called the continue chunk, FXCO. This structure
is mostly private to Mand2000, but it is listed here anyway for
completeness.
struct restartinfo
{
BOOL picturedone; /* Always false if this structure is written. */
short levelstarted; /* Zero to three. */
short level, currentx, currenty, currenttopy, currentbottomy;
short blocksize, xskip; /* Current pixel size - 1,2,4 or 8. */
/* Jump distance - either blocksize */
/* or blocksize*2. */
short xgrid, ygrid; /* Offset of draw grid from top left. */
BOOL reflecttype; /* This says whether reflection is allowed, and what type. */
BOOL reflecting; /* This says whether reflection is currently being used. */
short zeroline; /* Line where c.i = 0. The x-axis. Only valid if reflecting is set. */
short zerocolumn; /* Line where c.r = 0. The y-axis. Only valid if reflecting is set. */
BOOL fractaltype; /* zero to five. */
struct region donebox[4]; /* Private - just ignore this data. */
};
With version 2.0 of Mand2000, a single CMAP chunk was no longer
sufficient. When fractals are saved in any of the True Colour modes (HAM,
HAM8 or dithered true colour) the CMAP palette is used for displaying the
data, and an additional palette is needed for storing the colours that the
user edits. This second palette is stored in a chunk called `FCMP'. The
format of this chunk is identical to the `CMAP' chunk, and Mand2000 will
always store 256 colours in these chunks.
Finally, Mand2000 optionally uses a custom chunk called `FITR' to
stored Fractal ITeRation information. When the iteration data is saved in
this chunk, Mand2000 can reload the file and then adjust the colour
mapping, without recalculating anything. This chunk also allows ADPro's
Fractal2000 loader to load Mand2000 pictures in as 24 bit images. There
are many other applications for the iteration data in this hunk. If you
are interested in writing a program that uses Mand2000 iteration
information, please contact us for information on the chunk format.